Release 10.1A: OpenEdge Development:
Programming Interfaces

ROWID and RECID data types

Progress provides two structure types to support record fetches. One structure type, the index, you define in the schema of your database. The other structure type, a results list, is temporary; Progress builds it at runtime. The results list associated with a DO, REPEAT, or OPEN QUERY statement with the PRESELECT option is sometimes called a preselect list.

In addition, there are two data types, ROWID and RECID, that allow you to retrieve a pointer to a fetched record. You can use this pointer to:

Position to and retrieve a record from a results list.
Refetch a record and modify its lock status.
Store as a future record reference.

In addition to the examples in this section, you can learn more about ROWID in OpenEdge Development: Progress 4GL Handbook .

Comparing ROWID and RECID

ROWID is supported by all DataServers. Earlier Progress versions provide RECID as the only way to fetch a record pointer (supported in this version for backward compatibility). RECID is limited to a 4-byte record address supported by only a few DataServers and standard Progress. ROWID provides a variable byte string that can represent a record address for any type of DataServer. For DataServers that use the 4-byte address supported by RECID (including Progress), ROWID also uses a four-4 value. Thus, there is no loss in performance using the more portable ROWID instead of RECID.

Returning record ROWID values

Progress provides a function named after the ROWID data type to return ROWID values. Given a buffer name, the ROWID function returns the ROWID of the current record in the buffer. This example fetches the first customer record, and if it has a balance, refetches it to lock it for update:

DEFINE VARIABLE custrid AS ROWID. FIND FIRST customer NO-LOCK. custrid = ROWID(customer). IF balance > 0 THEN DO:     FIND customer WHERE ROWID(customer) = custrid EXCLUSIVE-LOCK.     UPDATE customer. END.

Storing and retrieving ROWID and RECID values

As shown in the previous example, you can store ROWID values in ROWID variables. You can also store them in work table fields. Thus, the following are valid ROWID storage definitions:

DEFINE VARIABLE wkrid AS ROWID EXTENT 20. DEFINE WORK-TABLE wtrid FIELD wkrid AS ROWID.

You cannot store ROWID values in database or temporary tables, but you can store their hexadecimal string representations using the STRING function. You can then retrieve the string as a ROWID value using the TO–ROWID function:

DEFINE TEMP-TABLE ttrid     FIELD ridfld AS CHARACTER. FOR EACH customer FIELDS (balance) WHERE balance = 0 NO-LOCK:     CREATE ttrid.     ASSIGN ttrid.ridfld = STRING(ROWID(customer)). END. DO TRANSACTION:     FOR EACH ttrid:         FIND customer WHERE ROWID(customer) = TO-ROWID(ttrid.ridfld).         DELETE customer.     END. END.

You can store RECID values directly in a database or temporary table.

Additional 4GL support

Several additional statements use ROWID and RECID values directly. For example, the REPOSITION statement sets the query position to a record given by its ROWID or RECID. For more information, see the "Results lists" section.

Also, because RECID is not supported by all DataServers, Progress provides the DBRESTRICTIONS function to indicate whether a particular DataServer supports it.

Converting from RECID to ROWID

When changing an application to use ROWID that currently uses RECID, you can complete the change with only a keyword substitution if your application:

Does not reference RECID values as integers.
Does not store RECID values in database or temporary tables.

Otherwise, after you change all RECID references to ROWID, you must rewrite your integer references to use character strings. If you use database or temporary tables, you must also convert the relevant fields to CHARACTER fields, and use the STRING and TO–ROWID functions to store and retrieve ROWID values. However, note that some DataServers build a string for a single ROWID that can reach up to several hundred bytes (including a complete WHERE clause).

All DataServer tables support ROWID references except those, such as views, that do not have unique row identifiers. DataServers from earlier Progress versions also support ROWID references. Progress Versions 7.3A and later use an internal RECID that transparently converts to a ROWID in the client.

Writing DataServer-portable applications

The least portable feature of ROWID references is the scope of a ROWID reference and when it changes for each DataServer. To maximize portability, follow these rules:

Always assign values to unique keys before returning the ROWID value of a record. Some DataServers use a unique key to generate the ROWID value.
If you UNDO a DELETE of a record for which you have stored the ROWID value, return the ROWID value again after the UNDO. It might be different after the record is recreated.
If you update a unique key value for a record, return its ROWID again to replace any prior value.
Never expect a record to have the same ROWID value between sessions.

Note that each DataServer uses a different method to generate a ROWID for a table, and sometimes for different tables in the same database. Therefore, never expect ROWID values to be identical, or even compatible, between otherwise duplicate tables from different DataServers.

For more information on ROWID value construction and scope for your DataServer, see your OpenEdge DataServer guide.